Typically, various organizations protect their internal networks by means of a firewall, which connects the internal network of the organization to public networks and filters and selectively discards the data packets entering and exiting the internal network according to predefined rules. Thus, a firewall is a gateway which operates at the same time as a connector and a separator between the networks in a sense that the firewall keeps track of the traffic that passes through it from one network to another and restricts connections and packets that are defined as unwanted by the administrator of the system. Physically a firewall is a machine with appropriate software to do the tasks assigned to it. It can be a router, a personal computer (PC), or whatever that can be used for such purposes.
Frequently, the filtering rules of a firewall are expressed as a table or list (rule base) of rules comprising data packet characteristics and related actions. Data packet characteristics are parameter values that are obtained from header field of a data packet and may be e.g. source IP (Internet Protocol) address, destination IP address and service (or protocol) or some other values. The action gives information about how to handle a data packet, which corresponds the data packet characteristics defined in the respective rule (i.e. which matches the rule). This means that for a data packet, which has the header information indicated in a rule, the action indicated in the rule is carried out. In a firewall, the action is typically deny or allow, which means the data packet is discarded or allowed to proceed, correspondingly.
The rules of a rule base are examined in certain order until a decision how to process the data packet is reached. The order of the rules in the rule base typically defines the order in which characteristics of a data packet are compared to the rules, that is, the rules are examined one by one from the beginning of the rule base. When a rule, to which the characteristics of a data packet match, is found, the action that is related to that rule is taken and often there is no need to continue examining the rules. However, the action defined in the rule may be conamining the rules. However, the action defined in the rule may be continue, in which case examining the rule base is continued from the next rule, or jump, in which case examining the rule base is continued from the rule specified in the jump action. The action of the firewall may be as well reject, which is similar to deny action. The difference is that deny action results in simply discarding the data packet and in reject the sender of the data packet is notified of discarding the data packet.
FIG. 1 illustrates as an example a rule base 10, having 5. rules. In each rule, a rule number, source IP address SRC ADDR, destination IP address DST ADDR, service (or protocol) and action are defined. However, this is only an example structure of rules, and also some other data packet characteristics may be defined in the rules. The rule #1. allows HTTP (HyperText Transfer Protocol) data from any address to a server with IP address 172.16.1.10.. All other HTTP traffic is denied with rule #2.. That is, if HTTP traffic does not match the rule #1, it is denied. Rules #3. and #4. allow FTP (File Transfer Protocol) traffic from network 10.1.1.0. to FTP server at IP address 192.168.1.15. and Telnet connections from network 10.1.1.10. to any address, respectively. The firewall rule bases are commonly designed to prohibit all that is not expressly permitted in the rules. Therefore, the last rule in the rule base is usually designed to deny any data packet. Rule #5 in the rule base 10. is such rule, that is, it denies data packets of related to any service from any source address to any destination address. So, if a data packet does not match any of the first four rules, it matches this last one and is denied.
In summary, when a data packet is received in the firewall, some of the header field values of the data packet are compared to the rules, which are stored in the firewall, and when a matching rule is found, the action related to the matching rule is taken.
Because all traffic intended to an internal network must pass through the firewall, most of the network security actions and policies can be concentrated in this particular point. This is of course a cost and administrative advantage, if the same policy can be used for a plurality of devices in the internal network. However, in some cases one firewall may be used for protecting plurality of independent subnetworks. For example, a Managed Service Provider (MSP) or a Managed Security Service Provider (MSSP) may offer firewall service to a plurality of customers by means of one firewall system. The problem in this approach is that the security requirements of different customers change frequently and when the configuration of one customer needs to be changed the configuration of the whole firewall needs to be changed and uploaded to the firewall again. This is a huge overhead in managing the firewall. Thus, there is a need for a “personalized” firewall configuration, that is, for possibility to flexibly alter firewall functionality associated to one user entity without need to reconfigure the whole firewall.
Another arrangement, where such personalized firewall is needed, is for example providing firewall service to a plurality of ADSL (Asymmetric Digital Subscriber Line) subscribers or wireless network users, the wireless network being for example GSM (Global System for Mobile communications), GPRS (General Packet Radio Service), or UMTS (Universal Mobile Telecommunications System). Such users usually do not want to or are not able to administer their own firewall, e.g. a personal firewall in their PC, but still require firewall protection. Additionally, In networks, where the IP address is dynamically addressed to a user, the address, which one user is using at a time, may change. An address may be assigned to a user by means of DHCP (Dynamic Host Configuration Protocol) or some other address assigning methods. In this case, the firewall is not generally interested in the IP address which originates or receives traffic, but rather the firewall needs to know who or what is using the address, since the IP address of one user may change over time, while the security requirements remain the same. This results in need of the personalization as well.
The closest solution for personalising a firewall that prior art has to offer is authentication of users. Authentication offers possibility to filter data packets according to users in addition to the IP address they are using at a time. The action in a rule may include the authentication of a user, that is, once the data packet matches a rule, the action may be: allow, if the user is X or if the user is one of X, Y, Z. Alternatively, authentication may be included in matching a data packet to a rule, that is, the rule matches only if authentication is successfully accomplished. Typically the user is requested to give his/her authentication credentials when a connection is attempted or the user has to authenticate separately in advance to opening connections through the firewall. This authentication can happen either in band (as a part of the protocol traffic) or out of band (using a separate channel). The authentication can be applied either to an IP address (one or more connections accepted from the same IP for a specified time) or a single connection.
There have also been attempts to provide a “single sign-on” (SSO) mechanism that fetches IP address-to-user (or user group) mapping information from an external system. That is, when a firewall processes a data packet, it takes the source IP address from the packet and queries from an external system identity of the user currently using that IP address. This enables the firewall administrator to write rules that have a user group as characteristics for identifying a data packet. This way, the source of the data packet in a rule may be a user group, and a data packet matches that rule if the user identity obtained from the external server belongs to the user group. Here the user does not need to authenticate separately for the firewall. Where this solution falls short is that the IP address-to-user binding must be refetched every time a data packet opening a new connection is processed. Also, the destination cannot be authenticated, since the authentication process requires user intervention and the receiver of some data may not be aware of the data arriving and thus cannot be assumed to be there to authenticate. Also, all users in one user group must have equal privileges, that is equal connections are allowed for them. Therefore, maintaining the user groups is tedious, especially if the rights one user has need to be changed and separate rule needs to be defined for each user group, which expands the rule base enormously. The alternative is to maintain separate rules for each user instead of a user group, but this clearly expands the rule base even more and clearly is not feasible.
However, authentication was originally designed to be used only rarely and causes a significant overhead both technically and especially to the users. This is especially true in case the exact identity of the user is required only for filtering the data the user is sending and not required for the service that is requested. For example, for simple web page browsing as such (sending and receiving HTTP data) does not usually require user identity, but it may be necessary for business purposes to allow this kind of traffic only to the customers paying for such a service, and therefore the user identity is required for filtering the traffic. Additionally, it is necessary to notice that authentication applies flexibly only to interactive, user-oriented traffic. Devices and software can also authenticate themselves, but this requires changes in the protocol that is used for changing information between the devices and therefore requires changes to both clients and servers. Thus it cannot be applied to existing systems without large modifications.
Due to above described deficiencies, authentication is not well suited to be used in connection with all users and all connections and thus not well suited for personalising a firewall. Therefore, currently there is no solution for truly personalizing a firewall.